1. Field of the Invention
The present invention relates to a computer system using intelligent input-output (I.sub.2 O), and more particularly, to a multi-processor computer system using at least one of its processors for processing I.sub.2 O transactions.
2. Description of the Related Technology
Use of computers, especially personal computers, in business and at home is becoming more and more pervasive because the computer has become an integral tool of most information workers who work in the fields of accounting, law, engineering, insurance, services, sales and the like. Rapid technological improvements in the field of computers have opened up many new applications heretofore unavailable or too expensive for the use of older technology mainframe computers. These personal computers may be used as stand-alone workstations (high end individual personal computers) or linked together in a network by a "network server" which is also a personal computer which may have a few additional features specific to its purpose in the network. The network server may be used to store massive amounts of data, and may facilitate interaction of the individual workstations connected to the network for electronic mail ("E-mail"), document databases, video teleconferencing, whiteboarding, integrated enterprise calendar, virtual engineering design and the like. Multiple network servers may also be interconnected by local area networks ("LAN") and wide area networks ("WANs").
A significant part of the ever-increasing popularity of the personal computer, besides its low cost relative to just a few years ago, is its ability to run sophisticated programs and perform many useful and new tasks. Personal computers today may be easily upgraded with new peripheral devices for added flexibility and enhanced performance. A major advance in the performance of personal computers (both workstation and network servers) has been the implementation of sophisticated peripheral devices such as video graphics adapters, local area network interfaces, SCSI bus adapters, full-motion video, redundant error checking and correcting disk arrays, and the like. These sophisticated peripheral devices are capable of data transfer rates approaching the native speed of the computer system microprocessor central processing unit ("CPU"). The peripheral devices' data transfer speeds are achieved by connecting the peripheral devices to the microprocessor(s) and associated system random access memory through high speed information (data and address) buses.
The computers system has a plurality of information buses such as a host bus, a memory bus, at least one high speed local peripheral expansion bus, and other peripheral buses such as the Small Computer System Interface ("SCSI"), Extension to Industry Standard Architecture ("EISA"), Industry Standard Architecture ("ISA"), and Peripheral Component Interconnect ("PCI"). The microprocessor(s) of the computer system communicates with main memory and with the peripherals that make up the computer system over these various buses. The microprocessor(s) communicates to the main memory over a host bus to memory bus bridge. The peripherals, depending on their data transfer speed requirements, are connected to the various buses which are connected to the microprocessor host bus through bus bridges that detect required actions, arbitrate, and translate both data and addresses between the various buses.
A widely used peripheral expansion bus that may be used in IBM-compatible PCs, Apple computers and RISC workstations is a high speed expansion bus standard called the "Peripheral Component Interconnect" or "PCI." The PCI bus standard is microprocessor-independent and has been embraced by a significant number of peripheral hardware manufacturers and software programmers. A more complete definition of the PCI local bus may be found in the PCI Local Bus Specification, revision 2.1; PCI/PCI Bridge Specification, revision 1.0; PCI System Design Guide, revision 1.0; and PCI BIOS Specification, revision 2.1, the disclosures of which are hereby incorporated by reference. These PCI specifications are available from the PCI Special Interest Group, P.O. Box 14070, Portland, Oreg. 97214.
Computer system peripheral hardware devices, i.e., hard disks, CD-ROM readers, network interface cards, video graphics controllers, modems and the like, may be supplied by various hardware vendors. These hardware vendors must supply software drivers for their respective peripheral devices used in each computer system even though the peripheral device may plug into a standard PCI bus connector. The number of software drivers required for a peripheral device multiplies for each different computer and operating system. In addition, both the computer vendor, operating system vendor and software driver vendor must test and certify the many different combinations of peripheral devices and the respective software drivers used with the various computer and operating systems. Whenever a peripheral device or driver is changed or an operating system upgrade is made, retesting and recertification may be necessary.
The demand for peripheral device driver portability between operating systems and host computer systems, combined with increasing requirements for intelligent, distributed input-output ("I/O") processing has led to the development of an "Intelligent Input/Output" ("I.sub.2 O") specification. The basic objective of the I.sub.2 O specification is to provide an I/O device driver architecture that is independent of both the specific peripheral device being controlled and the host operating system. This is achieved by logically separating the portion of the driver that is responsible for managing the peripheral device from the specific implementation details for the operating system that it serves. By doing so, the part of the driver that manages the peripheral device becomes portable across different computer and operating systems. The I.sub.2 O specification also generalizes the nature of communication between the host computer system and peripheral hardware, thus providing processor and bus technology independence.
The I.sub.2 O specification, entitled "Intelligent I/O (I.sub.2 O) Architecture Specification," Draft Revision 1.5, dated March 1997, is available from the I.sub.2 O Special Interest Group, 404 Balboa Street, San Francisco, Calif. 94118; the disclosure of this I.sub.2 O specification is hereby incorporated by reference.
FIG. 1 illustrates a schematic block diagram of a multi-processor computer system. The computer system is generally indicated by the numeral 100 and comprises central processing units ("CPUs") 102, core logic 104, system random access memory ("RAM") 106, a video graphics controller 110, a local frame buffer 108, a video display 112, a PCI/SCSI bus adapter 114, a PCI/EISA/ISA bridge 116, a PCI/IDE controller 118, and PCI/PCI bus bridges 124a, 124b. The local frame buffer 108 connects to a video graphics controller 110 which interfaces and drives a video display 112. Single or multilevel cache memory (not illustrated) may also be included in the computer system 100 according to the current art of microprocessor computer systems.
The CPUs 102 are connected to the core logic 104 through a CPU host bus 103. The system RAM 106 is connected to the core logic 104 through a memory bus 105. The core logic 104 includes a host-to-PCI bridge between the host bus 103, the memory bus 105 and a first PCI bus 109. The local frame buffer memory 108, and PCI/PCI bridges 124a, 124b are connected to the first PCI bus 109. The PCI/SCSI bus adapter 114 and PCI/EISA/ISA bridge 116 are connected to the PCI/PCI bridge 124a through a second PCI bus 117. The PCI/IDE controller 118 and a network interface card ("NIC") 122 are connected to the PCI/PCI bridge 124b through a third PCI bus 115. Some of the PCI devices such as the local frame buffer 108/Video controller 110 and NIC 122 may plug into PCI connectors on the computer system 100 motherboard (not illustrated). PCI connectors 160 and 162 are illustrated connected to the PCI bus 117 and are for plugging PCI device cards into the computer system 100. Three PCI buses 109, 117 and 115 are illustrated in FIG. 1, and may have logical PCI bus numbers of zero, one and two, respectively.
Hard disk 130 and tape drive 132 are connected to the PCI/SCSI bus adapter 114 through a SCSI bus 111. The NIC 122 is connected to a local area network 119. The PCI/EISA/ISA bridge 116 connects over an EISA/ISA bus 113 to a ROM BIOS 140, non-volatile random access memory (NVRAM) 142, modem 120, and input-output controller 126. The modem 120 connects to a telephone line 121. The input-output controller 126 interfaces with a keyboard 146, real time clock (RTC) 144, mouse 148, floppy disk drive ("FDD") 150, and serial/parallel ports 152, 154. The EISA/ISA bus 113 is a slower information bus than the PCI bus 109, but it costs less to interface with the EISA/ISA bus 113.
When the computer system 100 is first turned on, start-up information stored in the ROM BIOS 140 is used to begin operation thereof. Basic setup instructions are stored in the ROM BIOS 140 so that the computer system 100 can load more complex operating system software from a memory storage device such as the disk 130. Before the operating system software can be loaded, however, certain hardware in the computer system 100 must be configured to properly transfer information from the disk 130 to the CPU 102. In the computer system 100 illustrated in FIG. 1, the PCI/SCSI bus adapter 114 must be configured to respond to commands from the CPUs 102 over the PCI buses 109 and 117, and transfer information from the disk 130 to the CPU 102 via buses 117, 109 and 103. The PCI/SCSI bus adapter 114 is a PCI device and remains platform independent. Therefore, separate hardware independent commands are used to setup and control any PCI device in the computer system 100. These hardware independent commands, however, are located in a PCI BIOS contained in the computer system ROM BIOS 140. The PCI BIOS is firmware that is hardware specific but meets the general PCI specification. Plug and play, and PCI devices in the computer system are detected and configured when a system configuration program is executed. The results of the plug and play, and PCI device configurations are stored in the NVRAM 142 for later use by the startup programs in the ROM BIOS 140 and PCI BIOS which configure the necessary computer system 100 devices during startup. After startup of the computer system 100, the operating system software including the I.sub.2 O software, according to the I.sub.2 O Specification incorporated by reference above, is loaded into the RAM 106 for further operation of the computer system 100. An I/O processor, a hardware device, called an I/O Processor ("IOP") 202, is utilized in conjunction with the I.sub.2 O Specification, as more fully described hereinbelow.
FIG. 2 illustrates a functional block diagram of the I.sub.2 O specification, which divides the peripheral drivers into two parts: 1) the Operating System Services Module ("OSM") 212 which interfaces with the host operating system ("OS") 200; and 2) the Device Driver Module ("DDM") 204 that executes on an IOP 202 and which interfaces with a particular hardware device, media or server (206) that the driver must manage. All of the modules are capable of communicating with each other across a common communication layer 208. As defined in the I.sub.2 O Specification, the IOP 202 is a platform (node) consisting of a processor, memory, and I/O devices that are managed independently from other processors within the system for the sole purpose of processing I/O transactions.
FIG. 3 illustrates the basic software architecture of an I.sub.2 O compliant system. A DDM can be a hardware driver module ("HDM") 308, an Intermediate Service Module ("ISM") 306, or both. These two modules interface with other components via a communication system comprised of two parts: 1) message layers 300 and 304 which operate in conjunction with the host operating system 200 and the IOP 202, respectively, to set up a communications session between parties (OSM-DDM or DDM-DDM); and 2) a transport layer 302 which defines how the two parties will share information. Much like a standard communications protocol, the message layers 300, 304 reside on the transport layer 302.
The communications model defined in the I.sub.2 O specification, when combined with an execution environment and configuration interface, provides the DDM 204 with a host-independent interface. The modules are able to communicate without knowledge of the underlying bus architecture or computer system topology. Messages form a meta-language for the modules to communicate in a manner that is independent of the bus topology and host OS interfaces. The communications model for the I.sub.2 O architecture is a message passing system. The I.sub.2 O communication model is analogous to a connection oriented networking protocol, such as TCP/IP, in which the two parties interested in exchanging messages utilize the communication layer 208 to set up a connection and exchange data and control.
FIG. 4 illustrates the basic I.sub.2 O communication model. When the OSM 212 is presented with a request from the host OS 200, it translates the request into an I.sub.2 O request (400) and invokes the host's Message Transport layer 402 to deliver the message. The OSM Message Transport layer 402 removes the first free message frame (MFA) 404 from the remote IOP's (202) inbound free list 408, places the request information into the MFA 404 and posts the inbound message 406 in the remote IOP's (202) inbound post queue 408. The remote IOP's (202) Message Transport layer 414 removes the message 412 from the inbound post queue 408, extracts the request information from the inbound MFA 412, returns the now-free MFA 412 to the Inbound free list 408, and dispatches the posted request 416 to the appropriate DDM 204 for processing,.
Upon completion of the request, the DDM 204 issues a response 420 that notifies the IOP 202 to dispatch the result back to the OSM 212 by sending a message through the I.sub.2 O Message Layer. The remote IOP's Message Transport Layer 414 removes a free MFA 422 from the outbound free list 426, places the response data 420 into the MFA 424, posts the MFA 424 into the outbound post list 426, and notifies the OSM 212 that a response is waiting. The host Message Transport Layer 402 reads the MFA 430 from the outbound post list 426, removes the response data 432 from the MFA, returns (writes) the now-free MFA 428 to the outbound free list 426, and returns the response 432 to the OSM 212. The OSM 212 behaves just like any other device driver in the host OS 200. The OSM 212 interfaces to host-specific Application Programming Interfaces ("APIs"), translating them to a neutral message-based format that is then sent to a DDM 204 for processing.
Referring now to FIG. 5, operations flow of a standard I.sub.2 O-compliant system is illustrated. The OS 200 of the host CPU(s) 102 issues an I/O request 500. The OSM 212 accepts the request 500 and translates it (step 502) into a message 504 addressed to the target DDM 204 running on the IOP 202. The OSM 212 invokes the host Message Transport layer 402 to deliver the message. The host Message Transport layer 402 queues the message 510 by copying it (step 508) across the PCI buses 109 and 117 into a message frame buffer on the remote IOP 202. The remote IOP 202 Message Transport 414 posts the message 514 to the event queue (step 512) of the DDM 204. The DDM 204 then processes the request (step 516).
After processing the message and satisfying the request (step 516), the DDM 204 builds a reply 520 (step 518), addresses the reply 520 to the initiator of the request, and invokes the remote IOP 202 Message Transport layer 414 to send the reply 524 to the initiator. The remote IOP Message Transport layer 414 queues the reply 524 by copying it (step 522), across the PCI buses 109, 117, into a message frame buffer residing at the host's Message Transport layer 402. The remote IOP 202 then alerts the host's Message Transport layer 402 that a message is ready for delivery. The host's Message Transport layer 402 invokes the OSM's 212 message handler (step 526) which retrieves the OS 200 I/O request 532 from the message in order to complete the OS I/O request (step 530). Finally, the request itself is returned to the OS 200 (step 528).
Referring now to FIG. 6, a schematic block diagram of a standard I.sub.2 O architecture is illustrated. The DDMs 204a and 204b are the lowest level modules in the I.sub.2 O environment, encapsulating the software which is specific to a particular controller and the associated peripheral devices (LAN 206a and disk 206b), in essence, providing an abstract device driver for the I.sub.2 O environment. The DDM translation layer is unique to each individual peripheral device and vendor, and supports a range of operating types, including synchronous, asynchronous request, event-driven, and polled. The DDMs 204a and 204b, which execute on the IOP 202, are managed by the I.sub.2 O real-time input-output operating system ("iRTOS") 608, which provides the necessary support for the operating system processes and bus-independent execution. DDMs in general may therefore be designed in a manner which minimizes changes when moving from one computer system hardware platform to another.
In order to support the I.sub.2 O device model, the I.sub.2 O specification defines a hardware architecture which uses a single host processor (which may consist of multiple processors 102a, 102b and 102c on a single host bus) and an intelligent I/O subsystem containing one or more physical hardware I/O processors 202. The I/O subsystem 202 has its own operating system 608, local memory (ROM and RAM) and local I/O bus(es) (not illustrated). The dedicated I/O processor(s) 202 may be located on a plug-in feature card, generally a PCI device card. Special memory must also be provided for each dedicated I/O processor so that both private and shared memory are available. The private memory is only used by the associated I/O processor 202, but the shared memory must be available to all of the computer system resources.
The shared memory, through appropriate memory address translators, is the vehicle through which different I/O processors and the host processor communicate with one another through the message and transport layers. Messages sent to the IOP 202 are allocated from the inbound free list 406 and placed in the inbound post queue 408 located at an address equal to the PCI card's base address plus 0x40 (hexadecimal) (600). Messages from the IOP 202 to the OSM 212 are allocated from the outbound free list 604 and placed in an outbound post queue 606 located at an address equal to the PCI card's base address plus 0x44 (602).
According to the I.sub.2 O Specification, these I/O processors (IOP 202) require a separate computer subsystem complete with its own dedicated microprocessor, memory, internal information bus(es) and printed circuit board real estate. This is neither cost effective nor practical for manufacturing general use computer systems having an optimal performance to cost ratio. In addition, legacy computer systems having only ISA and EISA buses could not utilize newer OS and peripheral devices running under the I.sub.2 O specification because of their lack of a PCI bus(es).
What is needed is a method and system for implementing intelligent distributed I/O processing, such as I.sub.2 O, in a multi-processor computer system without requiring special hardware for a dedicated I/O processor subsystem.